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An  Annotated  Bibliography  on  Integration  in  Software 

Engineering  Environments 

Abstract:  This  paper  provides  an  annotated  bibliography  on  integration  in  software  engi¬ 
neering  environments  (SEEs).  The  aim  is  to  provide  readers  with  a  source  of  information 
that  can  be  used  as  the  basis  fcr  more  detailed  studies  in  this  area. 

1.  introduction 


There  is  currently  a  great  deal  of  activity  within  the  software  engineering  community  in  the  area 
of  providing  automated  support  for  aspects  of  the  software  development  process.  The  diverse 
tools,  systems,  and  environments  that  have  resulted  all  have  the  basic  aim  of  supporting  (or 
automating)  some  part  of  the  software  development  process  with  the  expectation  that  the 
process  will  be  be  more  predictable,  less  expensive,  easier  to  manage,  or  produce  higher 
quality  products. 

While  many  successes  have  been  made  in  individual  areas,  perhaps  the  greatest  challenge  is 
to  integrate  these  successes  to  produce  an  effective  and  integrated  automated  environment 
that  supports  the  complete  software  development  life  cycle.  While  numerous  terms  have 
been  coined,  we  denote  those  environments  as  Software  Engineering  Environments  (SEEs). 
There  are  many  reasons  why  the  Individual  successes  have  not  been  reflected  in  the  success 
of  SEEs.  However,  perhaps  the  underlying  reason  is  that  amalgamation  is  not  equivalent 
to  integration.  The  difficulty  that  arises  is  in  precisely  stating  (both  in  terms  of  quality  and 
quantity)  why  integration  and  amalgamation  are  different,  and  how  integration  can  best  be 
achieved.  Factors  to  be  taken  into  account  include: 

•  Scale  —  the  size  and  complexity  of  a  SEE  bring  problems  of  management, 
control,  and  consistency. 

•  Lack  of  maturity  —  much  of  the  technology  that  is  being  used  in  SEEs  is 
immature.  As  a  result,  a  sufficient  body  of  relevant  knowledge  and  expertise 
still  needs  to  be  built. 

•  Diversity  —  a  wide  range  of  requirements  nriust  be  addressed  that  come 
from  many  different  classes  of  potential  SEE  users  (e.g.,  developers,  man¬ 
agers,  and  tool  builders),  many  types  of  possible  application  domains  (e.g., 
data  processing,  real-time,  and  financial  services),  and  many  different  struc¬ 
tures  of  organizations  that  may  wish  to  use  a  SEE  (e.g.,  size,  resources, 
and  work  habits). 

•  Technology  base  ~  a  SEE  attempts  to  tie  together  a  collection  of  different 
technological  bases  into  a  consistent  system.  For  example,  a  SEE  can  be 
seen  as  an  extended  operating  system,  a  complex  database  application,  a 
very  high-level  programming  language,  a  diverse  collection  of  user  interface 
systems,  or  any  combination  of  these. 

When  integration  requirements  are  combined  with  other  SEE  requirements,  the  problems 
increase.  For  example,  it  is  easy  to  see  conflicts  between  the  need  for  openness,  taiiorability. 
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and  extensibility  of  a  SEE  on  the  one  hand,  and  the  need  for  consistency  and  predictability  in 
a  SEE  on  the  other.  These  trade-offs  must  be  evaluated  within  the  context  of  integration. 

Not  unexpectedly,  the  result  is  a  wide  collection  of  views  on  what  integration  means  in  a  SEE, 
how  effective  integration  can  currently  be  achieved,  and  what  is  important  to  achieve  better 
integrated  SEEs  in  the  future.  Perhaps  the  best  that  can  be  said  is  that  all  of  these  views 
of  integration  are  meaningful  and  are  necessary  to  gain  a  deeper  understanding  of  SEEs 
and  their  architectures.  Appreciating  the  range  and  complexity  of  the  problem  is  essential 
to  potential  purchasers  of  SEEs,  environment  integrators,  tool  builders,  and  researchers 
investigating,  developing  and  enhancing  SEE  technology. 

This  document  contains  an  annotated  bibliography  on  integration  in  software  engineering 
environments.  The  references  cited  here  describe,  discuss,  and  analyze  integration  issues 
related  to  SEEs.  They  deal  with:  ways  of  characterizing  integration;  concepts,  models, 
approaches,  techniques  and  mechanisms  in  support  of  integration;  and  technologically  and 
socially  related  issues.  Our  criterion  in  selecting  papers  has  been  to  choose  papers  that  we 
believe  provide  insight  into  integration  beyond  a  single  tool  or  system.  Therefore,  it  is  not 
intended  that  this  bibliography  cover  every  tool,  system,  or  technology  that  claims  to  support, 
or  embody,  integration  in  a  SEE.  The  annotations  objectively  summarize  key  aspects  of  the 
papers;  the  authors  intentionally  avoided  comparisons  and  evaluations. 

Inevitably  in  such  a  venture,  relevant  references  are  omitted,  and  others  are  included  that  may 
not  directly  meet  the  established  goals.  However,  our  hope  is  that  this  document  provides 
an  important  source  of  information  for  all  those  interested  in  issues  concerning  tool  and 
environment  integration. 

The  authors  welcome  comments,  criticisms,  or  suggestions  for  additions  to  this  bibliography. 


2 


CMU  St;l-92-SR-8 


References 


[1]  Brown,  A.W.  and  McDermid,  J.A.,  Learning  from  IPSEs  Mistakes.  IEEE  Software, 
8(2):23-28,  March  1992. 

The  authors  argue  that  much  of  the  current  work  on  Integrated  Project  Support 
Environments  (IPSEs)  —  particularly  the  work  on  Public  Tool  Interfaces  (PTIs) 
—  is  of  limited  utility  because  it  focuses  too  heavily  on  the  latter.  To  support 
this  argument  they  present  an  approach  for  quantifying  the  degree  of  integration 
achieved  in  an  IPSE  and  apply  that  approach  to  some  existing  PTIs  and  IPSEs. 
Integration  is  defined  in  terms  of  five  orthogonal  dimensions:  interface  integration 
(consistency  of  user  interface):  technical  integration  (consistency  of  development 
methodology);  tool  integration  (data  sharing):  team  integration  (isolation  and 
communication  between  users  on  a  team  -  e.g.,  through  private  and  shared 
work  areas):  and  management  integration  (derivation  of  management  information 
directly  from  technical  information  produced  by  software  engineers). 

The  authors  claim  that  various  degrees  (or  levels)  of  integration  may  be  defined 
for  each  of  the  five  dimensions.  As  an  example,  they  propose  the  following  levels 
of  tool  integration  (from  highest  to  lowest): 

•  Method  level  (e.g.,  sharing  of  knowledge  about  how  the  data  is  used  in  the 
process) 

•  Semantic  level  (e.g.,  sharing  of  data  structure  definitions  and  the  meanings 
of  operations  on  those  structures) 

•  Syntactic  level  (e.g.,  sharing  of  data  structures) 

•  Lexical  level  (e.g.,  sharing  or  formatted  data) 

•  Carrier  level  (e.g.,  sharing  of  byte  streams) 

[2]  Brown,  A.W.  and  McDermid,  J.A.,  On  Integration  and  Reuse  in  a  Software  De¬ 
velopment  Environment.  In  F.  Long,  editor.  Software  Engineering  Environments, 
Ellis  Honwood,  Chichester,  England,  1991. 

This  paper  explores  the  relationship  between  integration  and  reuse  (i.e.,  reuse 
of  existing  tools).  Integration  is  characterized  in  the  same  way  as  In  the  authors' 
1992  paper  [1].  The  authors  argue  that  the  objectives  of  integration  and  reuse 
are  inherently  conflicting.  They  believe  that  in  principle,  reuse  (without  major 
re-engineering)  can  only  be  achieved  between  intrinsically  compatible  software 
tools.  As  a  result,  tools  that  exhibit  higher  levels  of  integration  (e.g.,  at  the  se¬ 
mantic  level)  would  have  to  be  designed  with  a  shared  understanding  of  the  data 
and  the  operations  on  the  data.  Hence,  we  could  not  expect  to  be  able  to  reuse 
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proach  is  based  on  a  central  object  store  and  includes  features  such  as  the  typing 
of  software  objects,  the  composition  of  tools  out  of  modular  tool  fragments,  the 
optimization  of  the  storage  and  rederivation  of  software  objects,  and  the  isolation 
of  tool  interconnectivity  information  in  a  single  centralized  object.  Odin  can  be 
thought  of  as  an  interpreter  fo'  ^  high-level  command  langnage  whose  operands 
are  the  various  large-grained  software  objects  in  the  data  repository  and  whose 
operators  are  tool  fragments.  Odin  enables  tool  integrators  to  specify  how  the 
tool  fragments  and  object  types  relate  to  each  other. 

There  are  two  central  constructs:  a  derivation  graph,  which  specifies  type  and  tool 
interconnections,  and  a  derivation  forest,  which  specifies  how  actual  instances 
of  types  are  related  to  each  other.  Those  concepts  are  described,  together  with 
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discusses  the  underlying  concepts  of  process-enacted  environments  from  the 
users’  standpoint,  the  means  of  implementation,  and  the  specific  requirements 
process  enactment  puts  on  tools.  It  then  presents  an  experimental  SEE,  devel¬ 
oped  by  Cap  Gemini  Innovation  within  the  context  of  the  Eureka  Software  Factory 
(ESF),  which  exhibits  a  number  of  the  required  characteristics.  The  authors  do 
not  characterize  tool  integration  per  se.  but  they  do  discuss  the  general  problem 
of  achieving  integration  while  retaining  independence  between  tools. 
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December  1990. 

This  paper  is  an  extended  version  of  [27].  The  main  additions  are  a  historical 
context  for  the  work  on  integration  by  reviewing  the  Ada  environments  work  in 
the  Stoneman  report,  followed  by  a  more  detailed  examination  of  possible  CASE 
integration  technologies  (such  as  databases,  data  interchange  formats,  and  mes¬ 
sage  passing).  A  number  of  standards  efforts  appropriate  to  tool  integration  are 
also  reviewed. 

[7]  Garlan,  D.  and  Ehsan,  I.,  Low-Cost,  Adaptable  Tool  Integration  Policies  for 
Integrated  Environments,  Proceedings  of  the  4th  International  Workshop  on 
Computer-Aided  Software  Engineering,  Irvine,  CA,  ACM  SlGSOFT  15(6):  1-10, 
December  1990. 

This  paper  demonstrates  how  tool  integration  based  on  message  passing  can  be 
extended/adapted  to  allow  dynamically  configurable  policies  of  tool  interaction. 
This  consists  of  augmenting  the  message  server  of  the  Field  environment  [16] 
with  a  mechanism  for  determining  how  to  decode  messages  sent  between  tools. 
The  result  is  that  when  the  message  server  determines  that  a  particular  tool  is 
interested  in  a  message,  a  set  of  policy  rules  is  consulted  to  determine  what  action 
to  take.  Such  policy  rules  are  independent  of  the  tools,  ana  can  be  amended 
without  a  need  to  change  either  the  message  server  or  the  tools. 

The  Forest  system  —  an  implementation  of  this  mechanism  —  is  described,  to¬ 
gether  with  its  facilities  for  multiple-user  policy  definition  support.  The  approach  is 
also  compared  to  similar  approaches;  Its  main  benefit  is  to  provide  the  capabilities 
of  more  general  and  costly  approaches  with  little  effort. 

[8]  Harrison,  W.,  Kavianpour,  M.,  and  Ossher,  H..  Integrating  Coarse-Grained  and 
Fine-Grained  Tool  Integration.  IBM  Research  Report  No.  RC17542,  IBM  T.J. 
Watson  Research  Center,  Yorktown  Heights.  N.J.,  ;991. 

This  paper  discusses  integration  of  coarse-grained  and  fine-grained  systems. 
The  granularity  refers  to  both  the  data  items  being  recorded  and  manipulated, 
and  the  control  operations  between  objects. 

The  problem  of  coarse  and  fine-grained  integration  is  examined  in  isolation, 
taking  PCTE  as  a  typical  system  that  provides  coarse-grained  data  integra¬ 
tion  through  objects  that  are  at  the  file  level,  and  weak  linkage  between  pro¬ 
cesses  through  message  queues.  The  fine-grained  example  used  is  an  Object- 
Oriented  Database  (OODB),  which  allows  much  smaller-sized  objects  (at  the 
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single  program-statement  level),  and  has  control  through  message  invocation  of 
the  operations  encapsulated  with  the  data  objects. 

The  paper  then  describes  in  more  detail  how  the  PCTE  system  could  be  extended 
with  an  OODB  to  provide  bCiC  coarse  and  fine-grained  integration.  The  aim  is  to 
provide  a  migration  pe*ti  the  fine-grained  support  that  the  authors  believe  will 
be  the  future  for  enviionments. 

[9]  Lewis.  G.R.,  CASE  Integration  Frameworks.  SunTech  Journal,  3(5):50-51. 
November  1990. 

Thi',  ’  aper  describes  a  short,  but  useful  summary  of  the  possible  approaches  to 
tool  integration  together  with  a  discussion  of  the  reasons  why  a  tool  integration 
standard  is  important,  and  requirements  on  practical  tool  integration  standards. 
It  discusses  data  and  control  integration  aspects,  including: 

•  Data  linkage,  i.e.,  establishing  semantic  relationships  between  pieces  of 
information  maintained  by  different  tools 

•  Data  interchange,  i.e.,  transferring  information  between  tools  in  some  mu¬ 
tually  agreed  representation 

•  Data  sharing,  i.e.,  tools  accessing  data  in  a  mutually  accessible  place 

•  Interprocess  control,  i.e.,  a  tool  causing  some  action  to  be  performed  in 
another  tool 

•  Meta  control,  i.e.,  a  co-ordinating  agent  to  sequence  tool  actions 

•  Advanced  data  linkage  support,  i.e.,  using  general  underlying  data  inter¬ 
change  and  interprocess  control  mechanisms 

Useful  diagrams  summarizing  the  different  ways  in  which  tools  can  exchange 
information  are  provided. 

{10]  Mi,  P.  and  Scacchi.  W.,  Process  Integration  in  CASE  Environments.  IEEE 
Software,  8{2):45-53.  March  1992. 

This  paper  defines  process  integration  as  a  way  to  represent  development  activ¬ 
ities  explicitly  in  a  software  process  model  to  guide  and  coordinate  development 
and  to  integrate  tools  and  objects;  their  implementation  strategy  is  to  realize 
process  integration  using  existing  CASE  environments  or  tool'>. 

The  advantages  of  process  modeling  and  enactment  are  discussed,  and  a  par¬ 
ticular  software  model  and  enaction  mechanism  is  presented.  Different  process- 
based  SEE  user  interfaces  are  illustrated,  distinguishing  between  a  software 
developer  and  a  process  manager’s  needs. 

These  ideas  are  then  illustrated  with  the  Softman  experiment  —  a  migration  of  an 
existing  CASE  environment  into  a  user-interactive  process  driven  environment, 
by  instantiating  their  process  model  into  the  Softman  process  model  and  inte¬ 
grating  Softman's  object  model  and  tool  set.  Details  of  the  resultant  system  are 
described. 

(11]  Morris,  E.,  Feiler,  P.,  and  Smith,  D.,  Case  Studies  in  Environment  Integration, 
Technical  Report  CMU/SEI-91-TR-13,  Software  Engineering  Institute,  Carnegie 
Mellon  University.  Pittsburgh,  PA,  May  1991. 
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This  paper  provides  a  useful  set  of  observations  with  respect  to  integration, 
based  on  case  studies  of  four  software  engineering  environments.  The  systems 
studied  are:  the  Boeing  Automated  Software  Engineering  Environment  (BASE), 
the  Rome  Airforce  Laboratory  funded  Software  Life  Cycle  Support  Environment 
(SLCSE),  the  Verdix  VADS  APSE,  and  Hewlett  Packard  SoftBench  environment 
[3],  it  examines  the  environment  standards,  implementations,  and  technology 
that  proved  useful  in  the  integration  of  tools  into  these  environments. 

The  observations  are  concerned  with  the  current  state  of  tool  and  environment 
integration  and  trends  in  integration;  they  deal  with  aspects  of:  tool  maturity, 
vendor  egocentrism,  conservative  integration,  virtual  interfaces,  user  interface, 
data  interchange,  process  support,  framework  support,  data  granularity,  and 
programming  in  the  large.  Those  observations  we.’^e  also  based  on  surveys  with 
environment  and  tool  builders  at  two  workshops.  Key  trade  offs  for  SEE  builders 
and  users  are  also  identified. 

[12]  Nejmeh,  B.,  Characteristics  of  Integrabte  Software  Tools,  INTEG.SAA/.TOOLS- 
89036-N,  Version  1.0,  Software  Productivity  Consortium,  Inc.,  Herndon,  VA. 
1989. 

This  pciper  discusses  four  dimensions  of  integration  in  a  software  development 
environment:  data  integration;  presentation  integration;  interoperability  integra¬ 
tion;  and  process  integration.  They  are  variatio.ns  of  Wasserman's  definitions 
[25]. 

This  paper  also  describes  characteristics  of  integrable  tools,  i  e.,  characteristics 
that  make  a  tool  easy  to  add  to  Software  Development  Environments,  and  dis¬ 
cusses  those  characteristics  as  they  relate  to  the  four  dimensions  of  integration. 

The  integration  characteristics  were  classified  into  four  categories:  environment 
sensitivity  (e.g.,  location  independence),  characteristics  to  allow  a  tool  to  peace¬ 
fully  co-exist  with  other  tools;  interoperability  (e.g.,  data  import),  characteristics  to 
facilitate  interoperability  among  tools;  extensibility  and  adaptability  (e.g.,  object 
scnema  extension),  characteristics  to  facilitate  tool  extension  or  adaptation;  and 
standards  characteristics  (e.g.,  portability)  related  to  conformance  to  star.dards. 

[13]  Oliver,  H.,  Adding  Control  Integration  to  PCTE.  In  Software  Development  Envi¬ 
ronments  and  CASE  Technology,  A.  Enders  and  H.  Weber,  editors,  number  509 
in  Lecture  Notes  in  Computer  Science,  pages  69-80.  Springer-Verlag,  Berlin, 
1991. 

The  main  theme  of  this  paper  is  the  need  to  combine  different  forms  of  integration 
in  a  software  engineering  environment,  particularly  data  and  control  integration 
mechanisms.  The  focus  of  the  paper  is  a  set  of  experiments  carried  out  at  Hewlett- 
Packard  aimed  at  re-implementing  SoftBench  (which  provides  control  integration) 
on  top  of  PCTE  (which  provides  data  integration).  Details  of  these  experiments 
are  given,  followed  by  some  thoughts  on  the  likely  usefulness  of  the  resultant 
system. 

[14]  Penedo,  M.  H.,  and  E.  D.  Stuckle,  PMDB  -  A  Project  Master  Data  Base  for 
Software  Engineering  Environments,  Proceedings  of  the  8th  International  Con¬ 
ference  on  Software  Engineering,  London,  August  1985. 
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This  paper  describes  a  model  of  the  entire  life  cycle  in  terms  of  data  and  relation¬ 
ships;  the  model  is  denoted  the  Project  Master  Data  Base  (PMDB)  Model.  The 
PMDB  model  is  a  conceptual  or  logical  life  cycle  schema  to  be  used  as  a  com¬ 
mon  data  interoperability  model.  The  model  can  also  be  used  as  oart  of  a  SEE 
user  interaction  paradigm,  since  it  reflects  users’  perspectives  of  the  data  used 
in  their  project  activities.  Key  concepts  that  influenced  the  design  of  this  model 
were  the  need  to:  support  large  projects’  needs,  model  the  full  life  cycle  from 
proposal  to  delivery,  provide  a  generic  model,  avoid  redundancy,  and  exclude 
implementation  issues. 

This  paper  reports  the  initial  results  of  the  PMDB  work.  It  presents  the  PMDB 
model,  an  entity-relationship  model  consisting  of  31  types  (e.g.,  requirement, 
interface,  software  component,  resource,  task,  person,  milestone);  approximately 
200  attributes  associated  with  the  types  and  approximately  200  relationships 
between  types.  The  paper  also  discusses  technical  issues  in  the  definition  and 
design  of  an  environment  database  implementing  such  model. 

[15]  Perry,  D.  and  Kaiser.  G.,  Models  of  Software  Development  Environments,  IEEE 
Transactions  on  Software  Engineering,  17(3).  March  1991. 

This  paper  has  a  dual  focus:  first,  it  presents  a  general  model  of  software  de¬ 
velopment  environments  (SDEs)  in  terms  of  their  structures,  mechanisms,  and 
policies;  second,  it  explores  the  application  of  this  model  (the  SMP  model)  to  the 
classification  of  SDEs.  Tool  integration  is  discussed  as  it  relates  to  structures, 
mechanisms  and  policies  that  characterize  integrated  SDEs.  For  instance,  the 
authors  note  that  the  more  complex  structures  required  by  integrated  environ¬ 
ments  enable  more  sophisticated  policies,  but  make  it  harder  to  integrate  new 
mechanisms  and  policies  into  the  environment.  The  authors  classify  SDEs  ac¬ 
cording  to  the  scale  of  development  supported.  They  define  four  classes  of  SDEs, 
ranging  from  small-scale  (i.e.,  supporting-  individual  development)  to  large-scale 
(i.e.,  supporting  development  across  multiple  projects).  Each  class  of  SDE  is  an¬ 
alyzed  in  terms  of  its  prevalent  structures,  mechanisms,  and  policies.  This  same 
kind  of  analysis  is  also  applied  to  an  existing  taxonomy  of  SDEs  that  is  based  on 
historical  trends. 

[16]  Reiss,  S..  Connecting  Tools  Using  Message  Passing  in  the  Field  Environment, 
IEEE  Software.  7(4):57-66,  July  1990. 

This  paper  describes  an  approacii  to  tool  integration  based  on  message  passing, 
and  the  system  Field  developed  as  a  testbed  for  this  approach.  Reiss’s  thesis 
is  that  the  approaches  to  tool  integration  based  on  a  central  database  are  too 
complex  and  monolithic  to  provide  either  the  speed  or  flexibility  required  in  a 
software  development  environment.  He  believes  that  providing  a  central  message 
server  fc'lity  allowing  tools  to  communicate  via  message  passing  is  simple, 
flexible,  and  adequate  to  support  most  forms  of  tool  collaborations. 

The  Field  environment  is  described  in  some  detail.  It  is  a  system  supporting  three 
purposes:  a  programming  environment  for  teaching  undergraduates,  a  research 
programming  environment,  and  a  testbed  for  developing  new  tools.  It  combines 
the  selective  broadcast  communication  mechanism,  an  annotation  editor,  and  a 
set  of  specialized  interactive  analysis  tools. 
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The  Field  environment  has  been  influential  as  the  catalyst  for  a  number  of  com¬ 
mercial  products,  including  Hewlett-Packard’s  SoftBench,  Sun’s  ToolTalk,  and 
DEC'S  FUSE. 

[17]  Schafer,  W.  and  Weber,  H.,  The  ESF-Profi!e,  in  Handbook  of  CASE,  P.  Ng  and 
R.  Yeh.  Editors,  Van  Nostrand  Reinhold,  New  York,  1989. 

This  paper  presents  an  early  description  of  the  profile  of  the  Eureka  Software 
Factory  (ESF)  project  from  the  authors'  perspectives.  ESF  is  a  large  European 
research  effort  aiming  at  developing  flexible  concepts  for  the  integration  of  soft¬ 
ware  development  support  tools  that  have  been  built  at  different  sites,  and  the 
application  of  those  concepts  to  build  customized  software  factories. 

This  p^er  characterizes  the  ESF  factory  concept,  which  includes  a  reference  ar¬ 
chitecture,  a  reference  model,  and  an  instantiation  procedure  that  together  allow 
ESF  instances  to  be  derived.  The  ESF  reference  architecture  fixes  the  spectrum 
of  possible  ESF  instances,  where  iS  the  reference  model  defines  different  inter¬ 
faces  on  different  abstraction  leve's  for  each  architectural  component.  According 
to  the  authors,  the  result  is  that  any  new  tool  can  be  plugged  in  at  the  most 
suitable  level  of  abstraction  and  does  not  need  to  be  adapted  to  one  specific 
standard  interface. 

Five  degrees  of  integration  are  defined,  which  are  partially  ordered  in  that  one 
may  achieve  a  certain  degree  of  integration  only  if  certain  lower  degrees  of 
integration  have  already  been  achieved: 

1 .  Machine-integrated,  enabled  by  common  network  services 

2.  Object-integrated,  enabled  by  a  common  object  store  and  a  common  I/O 

manager 

3.  Process-integrated,  enabled  by  the  specification  of  a  software  development 

process 

4.  Method-integrated,  enabled  by  a  combination  of  object-integrated  and 

process-integrated,  to  achieve  sharing  of  information  at  the  semantic  level 

5.  Method-uniform,  enabled  by  a  single  development  method  throughout  the  life 

cycle 

The  ESF  reference  model  is  claimed  to  be  a  natural  extension  of  the  ISO/OS  I 
model.  To  support  integration  of  existing  tools,  the  ESF  reference  model  defines 
a  hierarchy  of  abstract  levels  of  communication  between  tools.  ESF  intends  to 
define/reuse  and  standardize  those  interaction  protocols,  also  called  Software 
Buses  [18].  Tools  are  integrated  at  different  levels  according  to  those  interaction 
protocols. 

[18]  Schuelke,  F.  and  Holtkamp,  B.,  The  Software  Bus  —  Communication  Aspects, 
University  of  Dortmund  Technical  Report,  Dortmund,  Germany,  March  1991. 

This  paper  presents  a  communication-oriented  view  of  the  Software  Bus,  which 
is  the  global  integration  mechanism  in  a  Factory  Support  Environment  (central 
concept  of  the  Eureka  Software  Factory  (ESF)  program).  The  Software  Bus 
goes  beyond  communication  to  be  a  mechanism  that  enables  the  plugging  of 
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components  that  make  up  a  software  factory  instance.  Four  major  service  areas 
are  to  be  supported  by  the  Software  Bus;  platform  management,  component 
management,  service  management,  and  tool  management. 

The  paper  identifies  needs  and  requirements  for  the  Software  Bus.  Emphasis  is 
placed  on  the  communication  capabilities  of  the  Software  Bus  and  how  MUSE, 
a  University  of  Dortmund  system  for  managing  the  interoperation  of  components 
in  a  distributed  environment,  can  be  used  as  a  Software  Bus.  The  paper  also 
describes  the  software  factory  reference  framework  (SFRF),  which  defines  the 
means  of  integration  for  Software  Factories.  It  is  defined  as  a  four-stage,  multi¬ 
layer  framework  consisting  of  the  following  stages; 

1.  interworking  of  human  users  or  user  groups 

2.  interaction  of  human  users  and  the  computing  system 

3.  interoperation  of  different  software  cap^ilities 

4.  interconnection  of  different  hardware  platforms 

[19]  Thomas,  I.,  PCTE  Interfaces;  Supporting  Tools  in  Software  Engineering  Envi¬ 
ronments.  IEEE  Software,  6(6);15-23.  November  1989. 

This  paper  describes  the  Portable  Common  Tools  Environment  (PCTE)  and  some 
aspects  of  the  PCTE  Added  Common  Tools  (Pact)  environment  with  respect  to 
the  use  of  the  PCTE  interfaces.  The  history  of  the  PCTE  effort  is  described, 
together  with  an  overview  of  the  PCTE  interface  itself.  PCTE  aimed  to  define  a 
public  tool  interface  to  be  used  as  a  portsJbility  interface  and  integration  support 
for  the  ESPRIT  software  tools.  The  Pact  environment  was  built  on  top  of  the 
PCTE  interface:  it  includes  a  set  of  common  services  and  a  set  of  integrated 
tools.  The  Pact  common  services  include  version  management,  data  query  and 
manipulation  primitives,  and  documentation  structure  management. 

The  experiences  with  the  Pact  project  are  discussed,  including  some  areas  that 
led  to  changes  and  additions  to  the  PCTE  interface  itself.  Four  areas  of  integration 
were  identified:  the  common  services,  the  use  of  the  object  base,  user  interface 
uniformity,  and  tool  composition. 

[20]  Thomas,  I.,  Tool  Integration  in  the  Pact  Environment,  Proceedings  of  the  11th 
International  Conference  on  Software  Engineering,  Pittsburgh.  PA,  May  16-18, 
1989,  IEEE  Computer  Society  Press,  Washington,  DC.  1989. 

This  paper  describes  the  PCTE  Added  Common  Tools  (Pact)  environment,  a  soft¬ 
ware  engineering  environment  built  on  the  PCTE  interfaces.  The  paper  describes 
the  Pact  architecture,  which  includes  a  set  of  common  services  and  a  toolset  built 
using  those  common  services.  The  Pact  common  services  include  version  man¬ 
agement,  data  query  and  manipulation  primitives,  and  documentation  stmcture 
management.  The  toolsets  discussed  in  the  paper  are:  configuration  manage¬ 
ment,  project  management  and  document  preparation  tools.  It  also  includes  a 
rationale  for  the  architecture  and  lessons  learned  about  the  benefits  and  disad¬ 
vantages  of  a  common  service  approach  to  environment  architectures  based  on 
Public  Tool  interfaces. 
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[21]  Thomas,  1„  Goals  and  Requirements  for  Integration  Frameworks.  Proceedings  of 
the  4th  International  Workshop  on  Computer-Aided  Software  Engineering,  Irvine. 
CA.  ACM  SIGSOFT  1 5(6) ;20 1-203,  December  1990. 

This  Short  paper  looks  at  the  requirements  for  a  tool  integration  framework.  It 
is  based  on  the  author’s  experiences  of  developing  the  PCTE  interface,  and  the 
requirements  that  were  imposed  on  it.  In  summary,  the  requirements  identified  for 
a  tool  integration  framework  are;  completeness  of  the  interface;  a  clear  migration 
path  for  existing  tools;  multi-language  development  support;  a  separation  of  policy 
issues  from  mechanistic  ones;  support  for  distributed  development;  scalability  of 
services  for  large-scale  development;  and  clear  identification  of  the  scope  of 
services  and  the  class  of  end-user  they  are  intended  to  support. 

[22]  Thomas,  I.  and  Nejmeh,  B.,  Definitions  of  Tool  Integration  in  Software  Engineering 
Environments,  IEEE  Software,  8(2):29-35,  March  1992. 

This  paper  presents  a  conceptual  framework  for  helping  to  determine  how  well  a 
tool  is  integrated  within  a  software  engineering  environment.  It  defines  integration 
as  a  property  of  the  relationship  between  elements  of  an  environment.  However, 
it  focuses  on  integration  relationships  between  tools. 

Those  properties  are  defined  in  the  context  of  four  well-known  types  of  integra¬ 
tion;  presentation  integration,  data  integration,  control  integration,  and  process 
integration.  Those  properties,  described  together  with  support  mechanisms  that 
can  improve  them,  are: 

•  From  the  perspective  of  presentation,  af^arance  and  behavior,  and  inter¬ 
action  paradigm 

•  From  the  data  integration  perspective,  interoperability,  non-redundancy, 
data  consistency,  data  exchange,  and  synchronization 

•  From  the  control  integration  perspective,  provision  and  use 

•  From  the  process  integration  perspective,  process  step,  event,  and  con¬ 
straint 

The  authors  note  that  they  expect  this  set  of  proposed  relationships  and  properties 
to  be  extended  and  refined  as  the  understanding  of  tool  integration  grows, 

[23]  Wallnau,  K.C.  and  Feiler,  P.H.,  Tool  Integration  and  Environment  Architectures, 
Technical  Report  CMU/SEI-91-TR-11,  Software  Engineering  Institute,  Carnegie 
Mellon  University,  Pittsburgh,  PA,  May  1991. 

Both  an  overview  of  approaches  to  tool  integration  and  a  review  of  the  different 
types  of  tool  integration  are  provided  in  this  paper.  The  paper  compares  the 
centralized  approach  of  many  Integrated  Project  Support  Environment  (IPSE) 
solutions,  to  the  more  ad  hoc,  “point-to-point”  approaches  taken  by  many  CASE 
tool  vendors  in  forming  tool  coalitions.  The  conclusion  of  the  paper  is  that  these 
two  approaches  have  advantages  that  can  be  combined  in  future  systems.  This 
combined  approach,  called  "federated  CASE",  can  come  about  by  recognizing 
the  need  for  tool  integration  at  three  distinct  abstract  levels:  the  tool  mechanisms 
level,  the  tool  semantics  level,  and  the  tool  process  level. 
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[24]  Wasserman,  A.I.  and  Pircher,  P.A..  Visible  Connections,  Unix  Review,  4{10);62- 
73,  October  1986. 

This  paper  looks  at  the  need  to  provide  an  "open  architecture”,  believing  that 
this  implies  that  system  components  must  be  connected  in  visible  ways.  Exam¬ 
ples  of  open  architectures  are  discussed,  including  Unix  and  others  based  on 
a  common  file  format.  The  need  for  software  architectures  to  have  equally  ‘Vis¬ 
ible  connections”  is  then  discussed.  The  openness  is  described  at  four  levels: 
the  environment  level,  tool  level,  data  repository  level,  and  file  interface  level. 
The  Software  through  Pictures  (StP)  product  is  then  described  in  terms  of  its 
openness  at  each  of  these  four  levels. 

[25]  Wasserman.  A.I.,  Tool  Integration  in  Software  Engineering  Environments,  Pro¬ 
ceedings  of  Software  Engineering  Environments:  International  Workshop  on  En¬ 
vironments,  Chinon,  France,  September  18-20,  1989,  F.  Long,  editor,  number 
467  in  Lecture  Notes  in  Computer  Science.  Springer- Verlag,  Berlin,  1990. 

This  paper  proposes  five  types  of  tool  integration  and  discusses  levels  of  inte¬ 
gration  within  each  type.  The  types  of  tool  integration  are: 

1.  Platform  integration,  i.e.,  the  set  of  system  services  that  provides  network  and 

operating  systems  transparency  to  applications 

2.  Presentation  integration,  i.e.,  tools  that  share  a  common  ‘look  and  feel"  from 

the  user’s  perspective 

3.  Data  integration,  i.e.,  support  for  data  sharing  across  tools 

4.  Control  integration,  i.e.,  support  for  event  notification  among  tools  and  the 

ability  to  activate  tools  under  program  control 

5.  Process  integration,  i.e.,  support  for  a  well-defined  software  process 

The  paper  presents  a  structure  for  building  tools  that  advocates  isolating  the 
functionality  of  the  tool  from  its  internal  mechanisms  so  as  to  support  adaptation 
to  emerging  standards.  This  paper  also  presents  an  overview  of  the  integration 
techniques  employed  in  IDE's  Software  through  Pictures  environment,  using  the 
concepts  described  in  the  paper. 

[26]  Wileden,  J.,  Wolf,  A.,  Rosenblatt,  W.,  Tarr,  A.,  Specification  Level  Interoperability, 
Proceedings  of  the  12th  International  Conference  on  Software  Engineering,  Nice, 
France,  1990. 

This  paper  describes  an  approach  for  component  interoperability  denoted  as 
Specification  Level  Interoperability  (SLI),  which  provides  support,  as  indicated  by 
its  name,  at  the  specification  level.  The  approach  is  a  high-level,  representation- 
independent  approach  for  combining  software  components  written  in  different 
languages  or  that  run  on  different  machines. 

The  paper  discusses  some  representation-level  interoperability  (RLI)  mecha¬ 
nisms  and  the  SLI  approach,  which  consists  of  four  components: 

1.  A  unified  type  model,  i.e.,  a  notation  for  describing  the  entities  to  be  shared 
by  interoperating  programs 
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2.  Language  bindings,  which  connect  the  type  models  of  the  languages  to  the 

unified  type  model 

3.  Underlying  implementations,  which  realize  the  types  used  by  the  different 

interoperating  programs 

4.  Automated  assistance,  which  eases  the  task  of  combining  components  into 

an  interoper^le  whole 

The  SLI  approach  does  depend  on  RLI  mechanisms.  However,  the  paper  claims 
that,  if  fully  realized  and  properly  used,  SLI  can  be  a  type-safe,  extensible  mech¬ 
anism  for  tool/component  interoperability. 

The  paper  also  describes  a  prototype  realizing  the  model  and  experience  with  the 
use  of  the  prototype.  It  consists  of  a  unifying  type  model  called  UTM-0,  bindings 
for  Lisp  and  Ada,  an  implementation  strategy,  and  a  UTM-0  automated  generator. 

[27]  Wybolt,  N.,  Perspectives  on  CASE  Tool  Integration,  ACM  Software  Engineering 
Notes,  16(3);5&-60,  July  1991. 

This  paper  provides  a  short  overview  of  key  technical,  political,  and  economic 
issues  surrounding  CASE  tool  integration.  It  looks  at  some  of  the  common  ques¬ 
tions  of  CASE  integration  such  as  “where  does  the  data  reside?"  "How  do  the 
tools  communicate?”  and  “Who  carries  out  the  integration,  and  who  maintains 
it?”.  Some  of  the  technologies  proposed  to  answer  these  questions  are  then  re¬ 
viewed,  before  concluding  by  looking  at  some  of  the  real-world  practicalities  of 
providing  an  integrated  environment. 

[28]  Wybolt,  N.,  CASE  Repositories  and  Tool  Integration  —  A  Reality  Check,  Pro¬ 
ceedings  of  the  4th  International  Conference  on  Software  Engineering  and  its 
Applications,  Toulouse,  Prance,  December  1991. 

This  paper  discusses  data  repositories  in  the  context  of  tool  integration  and 
enumerates  a  number  of  potential  problem  areas  from  the  perspectives  of  the 
CASE  tool  supplier  and  end-user.  It  then  surveys  alternatives  to  the  repository 
and  its  problem  areas,  including  the  integration  of  links  and  message  switches, 
in  link  technology,  the  data  repository  is  replaced  by  a  network-wide  database  of 
links  between  objects  that  may  reside  in  the  same  or  different  databases  (e.g., 
NSE’s  Link  Service  Facility).  Message  switch  technology  embodies  a  mechanism 
whereby  tools  send  and  receive  messages  (e.g.,  HP’s  SoftBench). 

[29]  Zarrella,  P.,  CASE  Tool  Integration  and  Standardization,  Technical  Report 
CMU/SEI-90-TR-14,  Software  Engineering  Institute.  Carnegie  Mellon  University, 
Pittsburgh,  PA,  December  1990. 

This  paper  discusses  the  current  barriers  to  integration  of  CASE  tools  and  de¬ 
scribes  some  actions  being  taken  to  overcome  them.  It  addresses  the  issues, 
problems  and  resolution  efforts  related  to  CASE  integration  and  standardiza¬ 
tion  from  the  users’  perspective.  For  discussion  purposes,  CASE  tool  integration 
is  presented  according  to  five  areas:  single-vendor  (interna!)  tool  integration, 
multiple-vendor  (external)  tool  integration,  operating  environment  integration,  de¬ 
velopment  process  integration,  and  end-user  integration. 
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Issues  related  to  standardization  are  also  discussed,  and  a  summary  of  key  stan¬ 
dardization  efforts  and  their  status  is  presented.  The  author  sees  standardization 
efforts  as  a  possible  path  to  tool  integration,  but  conjectures  that  market-driven 
de  facto  standards  may  become  the  cornerstone  of  future  CASE  tool  evolution. 
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